A virtual closed network that is built up on the Internet is commonly called a Virtual Private Network (hereinafter abbreviated as VPN). The VPN is built using such a tunneling protocol as IPsec, L2TP or the like, and it is used for accessing a resource in a local area network (LAN) from a moving client via the Internet, or for interconnecting multiple physically dispersed local area networks via the Internet. In the case of authorizing a remote user to access a remote-access VPN, the following settings are required of both of the VPN client to access and the VPN gateway to be accessed.
VPN Client Unit:                IP address (global) of a VPN gateway unit        Mutual authentication information between the VPN gateway unit and a VPN client unit        Private IP address of the VPN client unit        Private IP addresses of a router and a name server (such as DNS,WINS) of an internal network of VPN (in the case of static setting on the part of the VPN client)        
VPN Gateway Unit:                Mutual authentication information between the VPN gateway unit and the VPN client unit        Private IP address to be delivered to an authenticated VPN client unit and private IP addresses of the router and the name server in VPN (in the case of dynamic setting/posting on the part of VPN client)        
In general, these settings affect security, and hence they must be done with security and with reliability, which places a heavy load not only on a VPN client unit user but also on a VPN administrator. And, when users accessible to this VPN change one after another, the burden of user management also becomes tremendous. Further, when a user accesses two or more VPNs, an authentication method, authentication information, and an IC card or similar authentication device for retaining them may sometimes differ for each VPN to be connected; the management therefor becomes a serious burden.
Occasionally the situation arises where the VPN client unit wants to temporarily exercise its granted VPN access authority in another VPN client unit. Further, in the case where the VPN client unit (A) is inside an NAT (Network Address Translation) segment or where it is a portable miniature device of severely limited power requirements, it is not proper to directly establish an encrypted channel for communication with the VPN gateway unit. In this instance, it is typical that another VPN client unit (D), which possesses the function of gateway from the NAT segment concerned to the Internet, takes the charge of establishing a tunnel to the VPN gateway. In this case, access control needs to be conducted for the VPN client unit (A), not for the VPN client unit (D). Thus, when the VPN client unit granted the access authority differs from the VPN client unit from which the tunnel starts, a mechanism for delegating authority is indispensable.
Moreover, depending on the property of the service offered by VPN, the VPN client unit user may sometimes want to avoid divulgence of personally identifiable information to the VPN service provider. On the other hand, the VPN service provider also wants, in many cases, to devote themselves to offering their primary services by outsourcing complicated operations such as handling client authentication information or similar personal information and management of members' admission and withdrawal. In this instance, the VPN service provider makes the outsourcer perform user authentication and verification of the access authority and introduce only valid users to the VPN service provider.
Secure distribution of the common key can be achieved by various methods (see patent documents 1 and 2, for instance). The method set forth in patent document 1 is a method that exchanges the common key between two or more communication units connected to a local area network; this method exchanges the common key via the gateway unit equipped with a DHC server function. More specifically, at the time of connecting the communication units to the local area network, the common key is exchanged simultaneously with acquisition of their IP addresses by DHCP. This permits exchanging the common key for encrypting communications in the local area network.
The method described in patent document 2 is a method by which, in the communication between the VPN client unit connected to the Internet and the communication unit connected to the local area network placed under the management of the VPN gateway unit, a common key is exchanged between the VPN client unit and the VPN gateway unit, and another common key is exchanged between the VPN gateway unit and the communication unit. This permits implementation of encrypted communication between the VPN client unit and the communication unit connected to the local area network without the need for a key exchange by an IKE or similar key exchange scheme between the VPN client unit and the communication unit connected to the local area network.
However, the method of patent document 1 limits the key distribution range to the local area network and the method of patent document 2 calls for pre-exchanging of the common key between the VPN client unit and the VPN gateway unit, and for these reasons, the management operations become complicated, for example, in the case where the admission and withdrawal of members of a society occur frequently. And either method does not provide a function of delegating access control to a third party and a function of allowing the VPN client unit to delegate encrypted communication processing to another reliable VPN client unit for access to the VPN gateway to which the VPN client unit is authorized to be connected. There are proposed various methods by which the VPN gateway side dynamically sets/posts the configuration management information, such as the private IP address to be delivered to the authenticated VPN client unit, private addresses of a router and a name server in VPN (see, for example, patent document 3, patent document 4, non-patent document 1, non-patent document 2, and non-patent document 3).
According to patent document 3, a management unit for management of setting information is provided, which logs in to a communication unit by presenting thereto its IP address and a log-in password to transfer the setting information. With this method, configuration management information, such as the private IP address and so on, can be distributed as setting information to the VPN client unit from the management unit corresponding to the VPN gateway unit. However, this method does not authenticate the VPN client unit that is a receiver—this poses a danger of impersonation attack by masquerading of the IP address and intermediator attack. Further, no mention is made of how the management unit performs authentication/access control when the VPN client unit issues a request for acquisition of the configuration management information.
Patent document 4, non-patent document 1, non-patent document 2 and non-patent document 3 all set forth methods of dynamic setting/posting of the configuration management information by such tunneling protocols as IPsec, PPP, L2TP, and the like. The present invention also makes an assumption that the function corresponding to the above-mentioned dynamic setting/posting is performed in the set-up phase of various tunnel protocols between the VPN client unit and the VPN gateway unit. But, according to the conventional systems, user authentication or access control and the dynamic setting/posting of the above-mentioned configuration management information are carried out as a single, integral operation at the time of tunnel set-up; in contrast thereto, according to the present invention, the user authentication and the access control are performed in a mediating apparatus to allow the VPN client unit and the VPN gateway unit to share a common secret, which is used to set up a tunnel between the VPN client unit and the VPN gateway unit, and then the configuration management information about the tunnel is dynamically set/posted from the VPN gateway unit. Besides, the VPN client unit A delegates the tunnel protocol processing for encrypted communication to another reliable VPN client unit D, by which it is possible to make a check of the access authority in the mediating apparatus for the source unit B. According to management convenience, part of the configuration management information on the tunnel, information for routing to the tunnel, or similar information about network operation, may be sent from the mediating apparatus to the VPN client unit. In this instance, the configuration management information sent from the mediating apparatus is set before or after tunnel setup in accordance with the kind of information. As an authentication and a certificate issuing method using a public key, there is proposed an SPKI (Simple Public Key Infrastructure) scheme (for example, non-patent document 4, and non-patent document 5), but it is not clear how to apply the scheme to the remote-access VPN.                Patent document 1: Japanese Patent Application Kokai Publication No. 2001-292135        Patent document 2: Japanese Patent Application Kokai Publication No. 2002-271309        Patent document 3: Japanese Patent Application Kokai Publication No. 2003-18163        Patent document 4: Japanese Patent Application Kokai Publication No. 2001-160828        Non-patent document 1: B. Patel, B. Aboba, S. Kelly, V. Gupta, “Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Model,” [online], published January, 2003. RFC3456, Internet Engineering Task Force, [Retrieved Mar. 17, 2003], Internet www.ietf.org/rfc/rfc3456.txt        Non-patent document 2: IPCP (RFC-1332)        Non-patent document 3: EAP (RFC-2284)        Non-patent document 4: C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, T. Ylonen, “SPKI Certificate Theory,” [online], published September 1999, RFC2693, Internet Engineering Task Force, Internet www.ietf.org/rfc/rfc2693.txt>        Non-patent document 5; C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, T. Ylonen, “Simple Public Key Infrastructure <draft-ieft-spki-cert-structure-0.6.txt>” [online], published Jul. 26, 1999, Internet Engineering Task Force, Internet world.std.com/˜cme/spki.txt        